Method and system for associating parameters of containers and contained objects

ABSTRACT

A system and method for establishing associative relationships between properties of a contained object and corresponding parameters of a container application is disclosed herein. The present system contemplates the establishment of both mutual and unilateral associative relationships, with a particular relationship being specified via a user interface created upon instantiation of the contained object. Such associative relationships may be advantageously established without modification of the code comprising the contained object. In one aspect the present system facilitates implementation of selected functionality of a container application prescribed by an event script. In this context an association is created between an event arising within a contained object instantiated in a computing environment and a script associated with the container application. An event indication is generated in response to occurrence of a particular event within the contained object. In response, the event script is invoked and a sequence of script commands corresponding to the selected functionality are carried out. In another aspect the present system provides a system and method for creating an association between a tag source of a container application and a property of a contained object. Specifically, an associative relationship is defined between the tag source and the property, such associative relationship being determinative of the extent to which changes in the tag source and property will induce corresponding changes in the other.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/241,938, filed Feb. 1, 1999, entitled METHOD AND SYSTEM FORASSOCIATING PARAMETERS OF CONTAINERS AND CONTAINED OBJECTS, which claimspriority under 35 U.S.C. §119(e) to U.S. Provisional Application No.60/103,362, filed Oct. 7, 1998, entitled METHOD AND SYSTEM FORASSOCIATING PARAMETERS OF CONTAINERS AND CONTAINED OBJECTS, each ofwhich is incorporated by reference herein in its entirety.

FIELD OF THE INVENTION

This invention relates generally to data processing systems and, moreparticularly, to a method and system for creating associations betweenparameters of a container application program and correspondingparameter of a contained object.

BACKGROUND OF THE INVENTION

The operation of a computer system is controlled by a computer programor group of programs called the operating system (“OS”). In earlyoperating systems, a computer user input text commands to the OS using acommand line interface. Later, more advanced operating systems weredeveloped which utilized a graphical user interface (“GUI”) incombination with an input device such as a mouse. In GUIs, the inputdevice controls a display cursor to allow for the selection of data andresources for application program operations. A user selects anoperation by highlighting an item or field and pressing a graphicalinput device button.

Many GUI programs are implemented in object-oriented programminglanguages, such as the C++ programming language. The display icons thatrepresent data or resources are typically representations of datastructures called objects, which encapsulate attributes and behaviors.Objects are specified by definitions, called classes, that specify theattributes and behaviors of the particular objects, which are termed“instantiations” of the class definitions. The reference Budd, T., “AnIntroduction to Object-Oriented Programming”, Addison-Wesley PublishingCo., Inc. 1991, provides an introduction to object-oriented concepts andterminology.

Object-oriented programming languages make it easier for systemprogrammers to implement the GUI concepts of icons and lists. Forexample, if the GUI icons are represented as object-oriented programmingobjects, the GUI program can be written so that the status of the iconis continuously updated. In this way, it is relatively simple for theGUI program to be written so that the icons can be selected with thegraphical user input device and moved about on the computer systemdisplay as desired.

With the advent of object-oriented GUIs also came object orienteddeveloping environments. Such development environments are computerprograms or groups of computer programs that allow a software developerto create object oriented programs. Object-oriented developmentenvironments typically have a palette of objects with which thedeveloper builds an application. Each object on this palette isdifferent and serves as a template for the developer. A palette object'sattribute settings are the default settings for that object. To use anobject on the palette, the developer copies the object and places thecopy on the application. The copied or “derived” object has the sameattribute settings as the original palette object.

Efforts have been made to establish a common method of communicationbetween objects instantiated within a given operating systemenvironment. For example, Microsoft Corporation has established acertain protocol, known as the Component Object Model, which governs theinteraction between software objects within the Microsoft Windowsoperating environment. COM provides a standard framework permittingobjects from different applications to share data and functions, andpermits a given application program (“container application”) to containmultiple objects of different types. Recently, a format for controlobjects known as “ActiveX” has been established to take advantage of theCOM protocol. An ActiveX object behaves as a “server” relative to itscontainer application, which in turn behaves as a “client”. The COMprotocol manages, among other things, the setup and initializationnecessary for container applications to send and receive messages anddata to and from server applications.

An ActiveX control is an object which typically includes data andfunctions, and which is capable of notifying its container applicationof the occurrence of an event. In the context of an ActiveX control,stored data members are known as “properties”, functions are referred toas “methods”, and event occurrences are denoted as “events”. Propertiescan be read from, and written to, an ActiveX control via associatedmethods. The interface of an ActiveX control is a set of methodsdefining certain input, output and behavior rules. Accordingly, acontainer application can invoke the methods of an ActiveX control toeffect the defined behavior and access the object data.

In addition to representing data stored by an ActiveX control,properties are used in formatting the display of an ActiveX control.Events are utilized to notify a container application of the occurrenceof an event, as well as to pass parameters relevant to the particularevent. For example, an ActiveX control is capable of informing itscontainer application of the occurrence of a selection event (e.g., whenthe user interface of the control has been “clicked on”).

ActiveX objects are typically implemented: (i) as in-process servers, or(ii) as out-of-process servers. In the former case the ActiveX controlis implemented as a Dynamic Link Library (“DLL”), and in the latter caseas an “executable”. ActiveX DLL's are loaded into the process space ofthe container application. As a consequence, data does not need to betransported between the container application and the ActiveX control.In contrast, ActiveX executables are loaded into a separate processspace from the container application. Since there is no shared memorybetween such applications, data is transported between ActiveX objectsand the container application. This is advantageous in the sense that anActiveX executable does not interfere with the processing of data in theclient application.

Although a number of programming environments exist for facilitatingdevelopment of Active X controls, as object-oriented constructs eachsuch ActiveX control operates independently of the containerapplication. That is, Active X controls are conventionally installed incontainer applications so as not to be affected by changes in parametersof the container application, and vice versa. Similarly, the occurrenceof ActiveX events does not automatically cause the execution of scriptsor the like in the container application. Although such relationshipsbetween the properties and events of an ActiveX control and a containerapplication could conceivably be established on an ad hoc basis, therehas not heretofore been a convenient mechanism for linking suchproperties and events with associated parameters of containerapplications.

SMMARY OF THE INVENTION

Briefly, the present invention provides a system and method forestablishing associative relationships between properties of a containedobject and corresponding parameters of a container application. Thepresent system contemplates the establishment of both mutual andunilateral associative relationships, with a particular relationshipbeing specified via a user interface created upon instantiation of thecontained object. It is a feature of the present invention that suchassociative relationships may be established without modification of thecode comprising the contained object.

In one aspect the present invention facilitates implementation ofselected functionality of a container application prescribed by an eventscript. In an initial step an association is created between an eventarising within a contained object instantiated in a computingenvironment and a script associated with the container application. In apreferred implementation this association is recorded in an event sinkof a control site serving the container application. An event indicationis generated in response to occurrence of a particular event within thecontained object. In response, the event script is invoked and asequence of script commands corresponding to the selected functionalityare carried out.

In another aspect the present invention provides a system and method forcreating an association between a tag source of a container applicationand a property of a contained object. Specifically, an associativerelationship is defined between said tag source and the property, suchassociative relationship being determinative of the extent to whichchanges in the tag source and property will induce corresponding changesin the other. This associative relationship is recorded within aproperty sink of a control site for the container application, and maybe specified by a user upon instantiation of the contained object.Depending upon the nature of the tag source, various unilateral andmutual associative relationships may be established. For example, incertain instances a unilateral associative relationship may be specifiedsuch that changes in the tag source are reflected as correspondingchanges in the property, while changes in the property are not permittedto affect the tag source. In other cases the converse unilateralassociative relationship, or a mutual associative relationship, may alsobe specified.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:

FIG. 1 is a block diagram of a computer system in which the presentinvention may be implemented.

FIG. 2 is a diagram of a dialog box for a bound object which has beeninstantiated in a container application in accordance with the presentinvention.

FIG. 3 provides a view of the dialog box of FIG. 2 in which the eventspage has been selected.

FIG. 4 provides a graphical representation of an instance of aninstalled object and the resulting control site established within awindow of a container application as a consequence of suchinstantiation.

FIG. 5 shows a block diagram of the structure of a property sinkincluded within the control site of FIG. 4.

FIG. 6 shows a block diagram of the structure of an event sink includedwithin the control site of FIGS. 4

FIG. 7 shows a tag object of a type identified by a particular field ofthe property sink of FIG. 5.

FIG. 8 provides a block diagram of the structure of a property object ofthe type identified by a particular field of the property sink of FIG.5.

FIGS. 9 and 10 are respective flowchart representations of the manner inwhich changes in properties of a container application potentiallyinduce corresponding changes in tags of an instantiated object, and viceversa.

DETAILED DESCRIPTION OF THE INVENTION Overview

The present invention provides a generalized method for creatingassociations between parameters of programming objects, such as ActiveXcontrols, and associated parameters of a container application. That is,properties and events of ActiveX controls are respectively bound to datavariables (i.e., “tags”) and scripts of the container application. Thecontainer application could comprise, for example, industrial automationand control software having tags representative of the state of varioussensors or industrial processes. Scripts of the container applicationinclude a sequence of script commands for invoking functionality of thecontainer application, thereby allowing a user to specify how theapplication operates.

FIG. 1 is a block diagram of a computer system 100 in which the presentinvention may be implemented. The computer system 100 includes a userstation 102 that communicates with a system storage unit over network106. The system storage unit 104 comprises a direct access storagedevice, such as magnetic disk storage, in which data files are stored.The user station 102 includes a central processing unit (“CPU”) 108, adisplay 110, and a main memory 112. The CPU operates in response to usercommands, which it receives via a keyboard 114 or graphical user inputdevice 116. The user station 102 can communicate with one or more otheruser stations or a network server unit over the network 106.

The main memory 112 contains a variety of data structures andinformation, including an operating system, application programs,program objects, and user data. The main memory is represented as asingle entity, but those skilled in the art will appreciate that themain memory can comprise a combination of random access memory (“RAM”),hard disk drives, optical disk drives, and other storage devicescontaining logically segmented storage locations. The main memoryincludes a computer program containing a sequence of programinstructions whose execution implements the present invention.

The operating system contained in the memory 112 supports anobject-oriented programming environment for the execution ofobject-oriented programs, such as those written in, for example, the C++programming language. Accordingly, the memory contains program objectsthat are data structures of an object-oriented programming language.Application programs are invoked, or launched, by a user through thekeyboard 114 or graphical input device 116. The application programs canbe written in a variety of languages, including C++.

The display 110 comprises a display device such as a video terminal thatdisplays computer output and indicates system operations. Displayobjects can be pictured on the display and the user can designate dataoperations on the display by using the input device 116 or equivalentgraphical user input device.

In an exemplary implementation the computer system 100 may also sendcommands to, and receive data from, one or more industrial sensor orprocess control devices 120. The state of each such device 120 isreflected by the value of an associated tag, each of which may be aparameter of the container application. In the exemplary implementationthe container application comprises an industrial automation softwareprogram, such as the InTouch program module developed by WonderwareCorporation of Irvine, Calif. The Wonderware Intouch module includes atool kit for building screens and interfaces, and a graphical userinterface for monitoring and controlling the devices 120. For example,in the context of electrical distribution the software toolkit of theWonderware Intouch module enables rapid development of three dimensionalrepresentations of electrical distribution switchgear. The switchgearelevational representations have logical connections to the switchgeardevices. An elevation can be modified to any dimensions with anessentially infinite number of combinations and arrangements of metersand protection devices to quickly and accurately represent a customer'sswitchgear. In addition, a tabular representation of metering andsetup/set point information is generated automatically with theappropriate database server links established. The Wonderware Intouchmodule is disposed to provide similar representations and accompanyingdatabase links in other areas of industrial automation and control.

Display and Editing of Associative Relationships

FIG. 2 is a diagram of a dialog box 150 for a bound object which hasbeen instantiated in a container application as described hereinafter.In the exemplary implementation of FIG. 2, the bound object comprises anActiveX control identified as TextControl. When instantiated in acontainer application using conventional techniques, the dialog box 150could be expected to include the “Control Name”, “General”, “Colors” and“Fonts” pages. In accordance with the invention, a “properties” page isincluded to provide a mechanism for viewing and altering relationshipsbetween properties of the bound object (i.e., TextControl) andcorresponding tags of the container application. In addition, an“events” page serves to display the relationship between various eventsof the bound object and associated scripts of the container application.

Referring to FIG. 2, the properties page of TextControl reveals that theproperty BackColor is bound to the tag backgroundcolor of the containerapplication. The arrow graphic 152 indicates that a bidirectionalrelationship has been established between the property BackColor and theassociated tag backgroundcolor. That is, changes in the value of the tagbackgroundcolor will be reflected in the value of the propertyBackColor, and vice versa.

FIG. 2 also indicates that the property BottomTextLine is bound to thetag textline3 of the container application. The arrow graphic 154indicates that changes to the tag textline3 will result in correspondingchanges being made to the property BottomTextLine. The solid verticalline at the right edge of the arrow graphic 154 indicates that a userwill not be permitted to define the relationship between BottomTextLineand textline3 such that changes to the former induce correspondingchanges to the latter. This situation may arise when, for example, thetag textline3 is “read only”, or when there exists some other reason whyit is impermissible to bind the tag textline3 to the propertyBottomTextLine.

It is also seen that that the property ForeColor is bound to the tagtextcolor of the container application. The arrow graphic 156 indicatesthat changes to the tag textcolor will result in corresponding changesbeing made to the property ForeColor. The absence of a right-pointingarrow in arrow graphic 156 indicates that changes to ForeColor will notaffect the value of textcolor. Since a solid vertical line does notappear at the right edge of the arrow graphic 156, a user will bepermitted to allow changes in the property ForeColor to causecorresponding changes in the tag textcolor.

FIG. 2 further shows the property TextJustification to be bound to thetag tag1. However, the absence of any arrow graphic proximate thedisplayed name tag1 indicates that changes to the propertyTextJustification will not induce changes in the tag tag1, nor viceversa.

FIG. 3 provides a view of the dialog box 150 in which the events pagehas been selected. This view reveals that the event Click is bound tothe script ClickScript of the container application. In the exemplaryimplementation of FIG. 3 no further graphic representation is providedof the binding between the event Click and the property ClickScript.

Referring again to FIG. 2, the associations between the parameters ofthe bound objects and corresponding tags of the container applicationmay be modified by using the graphical input device 116 to change thestate of the applicable arrow graphic. For example, in a particularimplementation each arrow graphic will cycle between various permittedassociative states (e.g., unidirectional, bidirectional) in response torepeated selection by the device 116.

Establishment of Associative Relationships Between CorrespondingParameters

In a preferred embodiment, the binding between a container applicationand a bound object is implemented using the capability of the underlyingwindow system. The present invention is described assuming, forexemplary purposes and without limitation, that the underlying windowsystem is similar to the Microsoft Windows 3.1 operating system(“Windows”). Except as otherwise noted hereinafter, conventionaltechniques are utilized to install objects (e.g., an ActiveX control)within the Windows environment for subsequent binding to a containerapplication in accordance with the invention. Once an object has beeninstalled, the process of binding an object to a container applicationin accordance with the invention is initiated by instantiating theinstalled object in the container application.

In an exemplary embodiment the container application comprises anobject-oriented industrial automation program such as, for example, theInTouch program developed by Wonderware Corporation of Irvine, Calif. Inthis exemplary embodiment the container application creates windowswhich themselves function as containers for ActiveX control objects.After a control object has been placed in such a window and itsparameter associations have been selected via a dialog box (FIG. 2), thewindow may be saved and closed in response to commands provided to thecontainer application. A compiling operation is preferably invoked whenthe container window and contained control object are saved, therebycreating a “compiled window”. The container window and contained controlobject may then be generated from the compiled window during subsequentexecution of the container application.

Upon such placement of an installed object in a window of the containerapplication, a dialog box such as that shown in FIG. 2 is presented viadisplay 110. The desired associations between properties of theinstalled object and tags of the container object may then be selectedvia pointing device 116 so as to create a bound object. Once one or moreinstalled objects have been so bound to the container application, thewindow of the container may be compiled with the bound objects so as tocreate a “compiled window”. During execution of the containerapplication the compiled window is read and interpreted, which resultsin the creation of the bound object within the run-time environment. Ina preferred implementation the compiled window is stored as a file ofpredefined format, in which each object (e.g., shapes, wizard utilities,ActiveX controls) present within the window of the container applicationis represented as a block of data. Utilization of a particularpredefined format for the compiled window file is not necessary forimplementation of the present invention, and differing file formats forthe compiled window may offer advantages in particular applications.

FIG. 4 provides a graphical representation of an instance 160 of aninstalled object and the resulting control site 162 established within awindow 166 of a container application as a consequence of suchinstantiation. Those skilled in the art will appreciate that a standardcontrol site having certain well defined properties is generated uponplacement of an object such as an ActiveX control within a window of aWindows compatible container application. In accordance with theinvention, the control site 162 differs from such a standard controlsite in that sets of one or more property sinks 168 and event sinks 170are provided to facilitate the parameter associations depicted in FIGS.2 and 3. The control site 162 defines a standard interface 172 forcommunicating with the instantiated object 160 through a correspondingstandard interface 174 thereof.

Referring to FIG. 5, there is shown a block diagram of the structure ofa property sink 168 included within the control site 162. The propertysink 168 defines a tagname field 178 for identifying the name of the tagto be associated with the property object specified by the pointerwithin the field 180. An association field 182 specifies the type ofassociation (e.g., unidirectional) to be established between the tagobject and property object identified by the pointers within the fields184 and 180, respectively. In the exemplary case of FIG. 5, theassociation field 182 would specify a unidirectional relationshipbetween the tag object textcolor and the property objectTextJustification. The association field 182 registers any change in therelationship between a tag object and corresponding property objecteffected using the pointing device 116 in the manner described abovewith reference to FIG. 2.

FIG. 6 shows a block diagram of the structure of an event sink 185included within the control site 162. The event sink 185 defines aDISPID field 186 containing an identifier corresponding to a givenevent. In addition, a CString field 187 is provided for storing the nameof a script for the container application associated with the event. Thename in the CString field is provided to the container application inresponse to occurrence of the given event, which executes thecorresponding script.

Referring to FIG. 7, there is shown a tag object 190 of the typeidentified by field 184 of the property sink of FIG. 5. The tag object190 includes a tagname field 192, PTACC handle field 194, and statusflag field 196. The contents of the tagname field 192 will be identicalto the contents of the tagname field 178 included within the propertysink 168. In a preferred embodiment the PTACC handle field 194 providesa unique identifier for a particular tag. This identifier is returned bya dynamically linked library (“DLL”) named “PTACC” to requesting thirdparty applications.

FIG. 8 provides a block diagram of the structure of a property object200 of the type identified by field 180 of the property sink of FIG. 5.As is indicated by FIG. 8, the property object 200 includes a DISPIDfield 202 for identifying a particular parameter of the bound object(e.g., ActiveX control). In an exemplary implementation the industrystandard dispatch interface (“IDispatch”) of the bound object furnishesan index stored in the DISPID field in response to a call by thecontainer application for a method of the bound object. The containerapplication then calls an “Invoke” method of the object's dispatchinterface, which causes the object to retrieve the method associatedwith the index in the DISPID field 202. The desired method is thencalled by the bound object.

The property object 200 further defines a “CString” field 204 forstoring the name of the tag corresponding to the container propertyassociated with such tag. Also included within the property object 200is an “ASSOCTYPE” field 206 which records the type of associationbetween such container property and tag. In addition, a “COcxTag” field208 is provided for storing a pointer to an object wrapper surroundingmethods used by the container application to interface with tags. Theproperty object 200 also defines a “COcxProperty” field 212 for holdinga pointer to an object wrapper surrounding methods for changingproperties of the bound object.

Mapping Changes Between Corresponding Properties and Tags

When a compiled window (described above) is loaded during execution ofthe container application, the property sinks 168 and event sinks 170associated with the compiled window are regenerated and used to recordany change in the operative association between properties of boundobjects and corresponding tags of the container application. FIGS. 9 and10 are respective flowchart representations of the manner in whichchanges in such properties potentially induce corresponding changes insuch tags, and vice versa.

Referring to FIG. 9, in step 220 a property of a bound object is causedto change in state or value (i.e., a “property change”) and theassociated control site (FIG. 4) of the bound object is notified (step222). It is then determined whether the notification received at thecontrol site is with regard to a property change (step 224). If not, nofurther processing relating to a potential change in the value of anassociated container tag is performed (step 226). If the notificationcorresponds to a property change, it is attempted to identify theproperty sink (FIG. 5) corresponding to the property being changed (step228). If a corresponding property sink is not found (step 230), then nofurther processing is performed (step 232). In the case where acorresponding property sink is identified, an OnEvent member function iscalled (step 234). The OnEvent member function serves to convert theproperty change into a corresponding change in state or value of theassociated tag (i.e., a “tag change”).

In step 236, an operation is performed to validate the proposed tagchange arising from the property change. In a preferred implementationthis validation process entails determining whether the proposed tagchange is within a predefined range of valid tag values. If the proposedchange is not validated (step 238), no further processing is performed(step 240). In the case where the property change is validated, thecontainer application makes the corresponding validated change in theassociated tag (step 242).

Referring now to FIG. 10, in step 250 a tag change is experienced by atag monitored by the container application and a notification message isgenerated in response. In step 254 it is then determined whether thenotification message corresponds to an industry standard “DBCHANGE”message (i.e., a type of message which has been registered in theWindows environment to facilitate interpretation by a receivingapplication). If not, no further efforts are made to make a propertychange corresponding to the tag change (step 256). If the window messagecorresponds to a DBCHANGE message, it is attempted to identify theproperty sink (FIG. 5) associated with the tag experiencing a change(step 258). If an associated property sink is not found (step 260), thenno further processing is performed (step 262). In the case where acorresponding property sink is identified, an OnTagChange memberfunction is called (step 264). The OnTagChange member function serves toconvert the tag change into a corresponding property change.

In step 266, an operation is performed to validate the parametersreturned by the OnTagChange member function. In a preferredimplementation this validation process entails determining whether theproposed property change falls within a predefined range. If theproposed change is not validated, no further processing is performed(step 267). In the case where the property change is validated (step268), a pointer to the appropriate property object is retrieved from theassociated property sink (step 270). If the retrieved pointer is invalid(step 272), then no further processing is performed (step 274). If avalid pointer has been retrieved, then a corresponding change is made inthe associated property via an interface of the application program(step 276).

In a preferred implementation of the procedure set forth in FIG. 10,several object classes described in CODE SECTION I are invoked.Specifically, CTagServer and CocxTag are classes disposed to “wrap”various methods for interfacing with the tags monitored by the containerapplication. Each “wrapper” instance of this class provides an interfacebetween the container application and any proprietary methods forinterfacing with such tags. The class CpropSink corresponds to aspecific implementation of a property sink. The class CocxProperty isdesigned to wrap properties of control objects and to store pointers(i.e., IDispatch) associated locations of such properties. The SetValuemember function uses the IDispatch pointer to change the value of acontrol object property associated with a tag experiencing acorresponding change. In CODE SECTION I, the “//” expression is used toidentifies comments to the code. CODE SECTION I CTagServer: LRESULTCTagServer::WindowProc(UINT message, WPARAM wParam, LPARAM lParam) {  if (message == m_DbChgMsg)   {    // interpret the lParam as a handleof a tag     HPT hPt = (HPT) lParam;     // Get the tag associated withthis message.     COcxTag* pTag = (COcxTag*) GetExtraLong(hPt, 0);    if (!pTag)     return false;     // Get the sink associated withthis tag.     ITagChange* pSink = (ITagChange*) GetExtraLong(hPt,sizeof(LONG));     // if there is a sink call it else call tags virtualmethod.     if (pSink)     pSink->OnTagChange(pTag);     else    pTag->OnTagChange(NULL);   return TRUE;   }   returnCWnd::WindowProc(message, wParam, lParam); } OnTagChange: voidCPropSink::OnTagChange(COcxTag*) {   // make sure there is a propertyobject associated with this tag   // if not then initialize one   if(!m_pProp)   InitProperty( );   // verify that there is a property, tagand that the association between   // the two indicates that the tagchanges the property (this relationship   // is defined by the graphicon the property page when the association   // is defined)   if(m_bIgnoreChange ∥ !m_pProp ∥ !m_pTag ∥   ((m_assocType !=TAG_CHANGES_PROP) &&   (m_assocType != BOTH)))   return;   // some flagshere solve some timing problems intended to solve   // circular events.ie. Tag change property which changes tag which   // changes property...  m_bIgnoreChange = true;   m_pProp->SetValue(m_pTag->GetValue( ));  m_bIgnoreChange = false;

Execution of Container Scripts in Response to Events

As is indicated by FIG. 3, the dialog box of a bound object representsany association existing between event occurrences in the object andscripts defined by the container application. In the exemplaryembodiment of FIG. 3, a user may alter such associations by performingediting operations upon the dialog box displayed by the events page.

In CODE SECTION II below, exemplary code is provided for effecting theassociation of event occurrences to the execution of container scriptscontemplated by the present invention. Specifically, CODE SECTION IIincludes the definition of a class “CScriptSink” disposed to facilitateimplementation of the event sinks described with reference to FIG. 6. Inparticular, CScriptSink causes event notification messages generated bythe bound object to be registered and sent to the container application.CODE SECTION II further includes definition of a class defined as“COcxItem”, which is responsible for creating control sites in responseto instantiation of bound objects as described above with reference toFIG. 4. Also defined is the member function “OnCmdMsg”, which isoperative to: (i) determine the type of an event notification which hasoccurred, (ii) locate the associated container script per therelationship defined in the applicable events page (e.g., FIG. 3), and(iii) cause execution of the associated script. Calls to the functionOnCmdMsg may be made in accordance with the standard COM protocol. CODESECTION II COcxItem: BOOL COcxItem::OnCmdMsg(UINT nID, int nCode, void*pExtra,       AFX_CMDHANDLERINFO* pHandlerInfo) {  AFX_EVENT* pEvent =(AFX_EVENT*) pExtra;  if (nCode == CN_EVENT && !m_bDesignMode)  {  COcxSink* pSink = NULL;   switch (pEvent->m_eventKind)   {    caseAFX_EVENT::event:    {     // get the event sinks          CStringsText;     pSink = m_EventSinks.GetItem(pEvent->m_dispid);     if(!pSink)      return false;     // create an event object         COcxEvent event(pEvent, this);          // Get the script namefor the current event          sText = pSink->GetText( );     // causethe script to execute          pSink->OnEvent(&event, sText);     returntrue;    }        //        // other cases here        //   }  }  returnCWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo); CScriptSink: voidCScriptSink::OnEvent(COcxEvent* pEvent, CString szScriptName) { CStringszComposed; CString szEventName; UINT  dwParamCount; UINT  dwIndex;CString szParamName; _variant_t vtParamValue; CEventTableUtil event; //essentially build up a structure that holds the types   // and valuesfor the script to execute properly   szEventName = pEvent->GetEventName(); dwParamCount = pEvent->GetParamCount( ); szComposed = szEventName;for (dwIndex=0; dwIndex < dwParamCount; dwIndex++) {  szParamName =pEvent->GetParamName(dwIndex);  vtParamValue =pEvent->GetParamValue(dwIndex);  szComposed += szParamName; event.AddNamedVariant((LPCSTR)szComposed, vtParamValue);  szComposed =szEventName; }   // register the message   wWizardCallMsg =  RegisterWindowMessage(“InTouchWizardCallMsg”);   // send theregistered message over to the main applicationOesExecuteScript(m_sText, pEvent->GetOcxInstanceName( ));   // clear outthe table of parameter information event.ResetContent( );

Although the above application has been described primarily in terms ofparticular implementations of techniques for creating associationsbetween contained objects and various parameters of containerapplications, one skilled in the art will be able to develop alternativeimplementations based upon the teachings herein. Thus the application ismeant only to be limited by the scope of the appended claims.

1. A method for creating a persistent association between a factoryautomation parameter of a container application operative within acomputing environment and a property of a contained object instantiatedwithin said computing environment, wherein said property relates toattributes of said contained object and said container application isconfigured to provide a visual interface representative of states ofsaid factory automation parameter, said method comprising the steps of:defining a persistent associative relationship between said factoryautomation parameter and said property, said persistent associativerelationship being determinative of the extent to which changes in saidfactory automation parameter and said property will induce correspondingchanges in the other; and recording said persistent associativerelationship within a property sink of a control site of said containerapplication, said control site being created upon instantiation of saidcontained object within said computing environment wherein saidcontained object facilitates provision of a visual indication of ones ofsaid states of said factory automation parameter.
 2. The method of claim1 wherein said factory automation parameter provides state informationrelating to at least one of said monitored parameters.
 3. The method ofclaim 2 wherein said state information is selected from the setconsisting of: pressure, temperature, and flow rate.
 4. A system forcreating a persistent association between a factory automation parameterof a container application operative within a computing environment anda property of a contained object instantiated within said computingenvironment, wherein said property relates to attributes of saidcontained object and said container application is configured to providea visual interface representative of states of said factory automationparameter, said system comprising: means for defining a persistentassociative relationship between said factory automation parameter andsaid property, said persistent associative relationship beingdeterminative of the extent to which changes in said factory automationparameter and said property will induce corresponding changes in theother wherein said contained object facilitates provision of a visualindication of ones of said states of said factory automation parameter;and a control site associated with said container application, saidcontrol site including a property sink within which is recorded saidpersistent associative relationship.
 5. The system of claim 4 whereinsaid factory automation parameter provides state information relating toat least one of said monitored parameters.
 6. The system of claim 5wherein said state information is selected from the set consisting of:pressure, temperature, and flow rate.
 7. A method for creating apersistent association between a tag source of a container applicationoperative within a computing environment and a property of a containedobject instantiated within said computing environment, wherein saidproperty relates to attributes of said contained object and saidcontainer application is configured to provide a visual interfacerepresentative of states of monitored parameters of an industrialprocess, said method comprising the steps of: defining a persistentassociative relationship between said tag source and said property, saidpersistent associative relationship being determinative of the extent towhich changes in said tag source and said property will inducecorresponding changes in the other; and recording said persistentassociative relationship within a property sink of a control site ofsaid container application, said control site being created uponinstantiation of said contained object within said computing environmentwherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters defined by said tag source.
 8. The method of claim 7 whereinsaid defining an associative relationship includes specifying aunilateral associative relationship permitting changes in said tagsource to be reflected as corresponding changes in said property, butnot permitting changes in said property to be reflected as correspondingchanges in said tag source.
 9. The method of claim 7 wherein saiddefining an associative relationship includes specifying a unilateralassociative relationship permitting changes in said property to bereflected as corresponding changes in said tag source, but notpermitting changes in said tag source to be reflected as correspondingchanges in said property.
 10. The method of claim 7 wherein saiddefining an associative relationship includes the step of specifying amutual associative relationship permitting changes in said tag source tobe reflected as corresponding changes in said property, and vice versa.11. The method of claim 7 wherein said defining an associativerelationship includes the step of selecting one of a plurality ofpredefined associative relationships.
 12. The method of claim 7 whereinsaid tag source provides state information relating to at least one ofsaid monitored parameters.
 13. The method of claim 12 wherein said stateinformation is selected from the set consisting of: pressure,temperature, and flow rate.
 14. The method of claim 7 further includingregenerating said property sink upon execution of said containerapplication and thereby creating a regenerated property sink, saidregenerated property sink recording changes to said persistentassociative relationship.
 15. A system for creating a persistentassociation between a tag source of a container application operativewithin a computing environment and a property of a contained objectinstantiated within said computing environment, wherein said propertyrelates to attributes of said contained object and said containerapplication is configured to provide a visual interface representativeof states of monitored parameters of an industrial process, said systemcomprising: means for defining a persistent associative relationshipbetween said tag source and said property, said persistent associativerelationship being determinative of the extent to which changes in saidtag source and said property will induce corresponding changes in theother wherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters defined by said tag source; and a control site associatedwith said container application, said control site including a propertysink within which is recorded said persistent associative relationship.16. The system of claim 15 wherein said means for defining anassociative relationship includes a user interface enablingspecification of a unilateral associative relationship, said unilateralassociative relationship permitting changes in said tag source to bereflected as corresponding changes in said property but not permittingchanges in said property to be reflected as corresponding changes insaid tag source.
 17. The system of claim 15 wherein said means fordefining an associative relationship includes a user interface enablingspecification of a unilateral associative relationship, said unilateralassociative relationship permitting changes in said property to bereflected as corresponding changes in said tag source but not permittingchanges in said tag source to be reflected as corresponding changes insaid property.
 18. The system of claim 15 wherein said means fordefining an associative relationship includes a user interface enablingspecification of a mutual associative relationship, said mutualassociative relationship permitting changes in said tag source to bereflected as corresponding changes in said property, and vice versa. 19.The system of claim 15 wherein said means for defining an associativerelationship includes a user interface enabling selection of one of aplurality of predefined associative relationships.
 20. The system ofclaim 15 wherein said property sink includes a first field for storing apointer to a tag object representative of said tag source, and a secondfield for storing a pointer to a property object representative of saidproperty of said contained object.
 21. The system of claim 20 whereinsaid tag object includes a tagname field and a status field, and whereinsaid property object includes a field indicative of said associativerelationship.
 22. The system of claim 15 wherein said tag sourceprovides state information relating to at least one of said monitoredparameters.
 23. The system of claim 22 wherein said state information isselected from the set consisting of: pressure, temperature, and flowrate.
 24. The system of claim 15 further including means forregenerating said property sink upon execution of said containerapplication in order to thereby create a regenerated property sink, saidregenerated property sink recording changes to said persistentassociative relationship.
 25. A system for creating a persistentassociation between a parameter of a container application operativewithin a computing environment and a property of a contained objectinstantiated within said computing environment, said containerapplication being configured to provide a visual interfacerepresentative of states of monitored parameters of an industrialprocess, said system comprising: a control site associated with saidcontainer application; and a property sink included within said controlsite, said property sink recording a persistent associative relationshipestablished between said parameter and said property duringinstantiation of said contained object within said computing environmentwherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters, said persistent associative relationship being determinativeof the extent to which changes in said parameter and said property willinduce corresponding changes in the other.
 26. The system of claim 25further including a user interface enabling specification of saidassociative relationship as a unilateral associative relationship, saidunilateral associative relationship permitting changes in said parameterto be reflected as corresponding changes in said property but notpermitting changes in said property to be reflected as correspondingchanges in said parameter.
 27. The system of claim 25 further includinga user interface enabling specification of said associative relationshipas a unilateral associative relationship, said unilateral associativerelationship permitting changes in said property to be reflected ascorresponding changes in said parameter but not permitting changes insaid parameter to be reflected as corresponding changes in saidproperty.
 28. The system of claim 25 further including a user interfaceenabling specification of said associative relationship as a mutualassociative relationship, said mutual associative relationshippermitting changes in said parameter to be reflected as correspondingchanges in said property, and vice versa.
 29. The system of claim 25wherein said property sink includes a first field for storing a pointerto a tag object representative of said parameter, and a second field forstoring a pointer to a property object representative of said propertyof said contained object.
 30. The system of claim 25 further includingmeans for regenerating said property sink upon execution of saidcontainer application in order to thereby create a regenerated propertysink, said regenerated property sink recording changes to saidpersistent associative relationship.